Skip to content

Task/cdd 3206 be filter db query for only is public true data#3079

Open
dandammann wants to merge 30 commits intomainfrom
task/CDD-3206-be---filter-db-query-for-only-is_public---true-data
Open

Task/cdd 3206 be filter db query for only is public true data#3079
dandammann wants to merge 30 commits intomainfrom
task/CDD-3206-be---filter-db-query-for-only-is_public---true-data

Conversation

@dandammann
Copy link
Copy Markdown
Contributor

Description

This PR includes the following:

Before I started this ticket:

The data model itself is not restricted, so Kathryn's previous work on CDD-2983: BE: Set is_public flag to be mandatory field
Test Completed
means we plan to ingest and store both is_public=True/False headline/time-series data in the near future.

The is_public flag only exists on headline/time-series row data. Access decisions are evaluated using request dimensions (theme, sub_theme, topic, metric, geography, geography_type) for those row queries, but this does not mean all metadata/master-table entities are globally filtered by is_public. Please evaluate whether this is acceptable, or if not, what should be done about that!

The codebase already contains RBAC (Role-Based Access Control) logic for headline/time-series data: non-authorized paths return public rows; authorized RBAC paths can include non-public rows when permitted.

New functionality I introduced:

I have now introduced an ENFORCE_PUBLIC_DATA_ONLY=True flag in /metrics/api/settings/auth.py that suppresses this RBAC functionality and only returns is_public=True dashboard API data. The following exceptions are intentional:

a) The API endpoints /api/audit/* can still return public and non-public diagnostic data.
b) Any API endpoints that serve metadata/master-table style data (not headline/time-series row payloads) remain unfiltered too.

If we later switch ENFORCE_PUBLIC_DATA_ONLY=False, the RBAC-based behaviour from point 3. above is re-enabled. The automation tests allow for the flag being either True/False, so will not have to be amended when the flag gets switched. Long-term all temporary enforcement code to do with ENFORCE_PUBLIC_DATA_ONLY should be removed, once the final application state and data flow has been achieved.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Tech debt item (this is focused solely on addressing any relevant technical debt)

Checklist:

  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added tests at the right levels to prove my change is effective
  • I have added screenshots or screen grabs where appropriate
  • I have added docstrings in the correct style (google)

@dandammann dandammann requested a review from a team as a code owner March 18, 2026 09:56
@sonarqubecloud
Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants